home *** CD-ROM | disk | FTP | other *** search
/ Network Supervisor's Toolkit / Network Supervisor's Toolkit.iso / printers / iprint / iprint.doc < prev    next >
Text File  |  1996-07-10  |  9KB  |  186 lines
  1. IPRINT is our own subset of NPRINT for 2.1x Netware. We have tested it (and
  2. are using it) with ANW 2.15 rev C. It will not work on any pre-2.1x Netware,
  3. and this probably includes ELS I.
  4.  
  5. The zip 1.02 file contains IPRINT.EXE, two .C files and one .H file.
  6. The program was written in Turbo C 2.0.
  7. Novell PSD "Netware C Interface" library is needed to recompiled and relink.
  8.  
  9. There is no distribution restriction or copyright or whatever applied to this
  10. software.
  11. This is 100% public domain software, you can use it and/or circulate in
  12. any form you want.
  13. On the other hand, we will do our best to correct reported problems, but
  14. as they all say, "the software is provided "as is" without warranty of any
  15. kind, etc, etc..."
  16. After all, why do you think we provided the source code for?...
  17.  
  18.  
  19.  
  20. IPRINT was originally developed because there are some annoying bugs
  21. in Netware printing utilities that were preventing us from using PS-PRINT
  22. the way we intended to, i.e. using FORM management to dynamically select a
  23. target printer out of several ran off the same queue.
  24.  
  25.  
  26. The bugs are:
  27.  
  28. - The F=<form name> option does not work. It should, since form is documented
  29.   as taking either F=<form number> or F=<form name> since 2.12 documentation
  30.   and may be before. But the later form does not work (at least in 2.15).
  31.   Since people tend to remember mnemonics mucho better than numbers, and
  32.   since mnemonic provide a level of indirection that allow us to reshuffle
  33.   the technical characteristics of the FORMS we use transparently to the
  34.   user, we considered this as a problem.
  35.  
  36. - When the F=<form number> option is used, NPRINT fills the <paper width>
  37.   and <paper length> fields of the Client Record Area in the Queue Block
  38.   with erroneous data. The error is that the paper size should be given as
  39.   two words in hi-lo bytes format, while it's actually given by NPRINT
  40.   in lo-hi bytes format. This only occurs when F=<number> is used.
  41.   The job profile JOB= option could not be used, since it does not retain
  42.   the form name of the profile (although PRINTCON asks for it when the
  43.   profile is defined <sigh>).
  44.   The result of the hi-lo inversion is that a form that is defined with a
  45.   132 columns width (ain't that regular?) is declared as 33792 columns wide
  46.   (actually -31744 columns!) in the queue block. While Novell printer
  47.   management does not seem to care, third party products such as PS-PRINT do,
  48.   and behave strangely when given such paper specs. PS-PRINT 3.0 prints the
  49.   right number of *totally blank* lines as the print job. Save a tree!
  50.  
  51. - Finally, we found out that PCONSOLE was putting the paper width information
  52.   in the right order, but at the wrong place: width was instead of length
  53.   and length instead of width, so regular 11 inches paper appeared to be 66
  54.   columns wide and 132 lines long, which is usually untrue. This resulted
  55.   in PS-PRINT truncating lines after column 66. Owell, at least, each number
  56.   was hi-lo, this time, so may be I'm asking too much.
  57.  
  58.  
  59. Since we needed to be able to submit print files AND to do it from the
  60. command line, and since we could not get any official fix, we decided to
  61. write our own "NPRINT", that we called IPRINT.
  62. Typing IPRINT with no parm displays the following Help screen:
  63.  
  64.  
  65. IPRINT - Net Print file   V 1.22  Mar 01 1990  C.m. I.R.C.I. 
  66.  
  67. Usage       : IPRINT file_spec [options..]
  68.               File_spec may be generic.
  69.  
  70. Options are :            Default
  71.  
  72.       File extension      [.LST]
  73.       /F=Form name/number [0]
  74.       /Q=Queue name       [Q_TEXT]
  75.       /C=number of Copies [1]
  76.       /T=Tab size         [8]
  77.       /NT No tabs
  78.       /NC Inhibit internal server copy
  79.       /S  Silent mode. Suppress copy progression display
  80.  
  81. Differences from NPRINT are as follow:
  82.  
  83. - As can be seen above, not all NPRINT options are supported.
  84.  
  85. - IPRINT accepts both F=<form name> and F=<form number>. If no form
  86.   parm is given, IPRINT defaults to F=0 and displays the corresponding
  87.   form name to the user. If an illegal form name / form number is given,
  88.   IPRINT reminds the user about legal form names. IPRINT uses the data
  89.   in NET$PRN.DAT as we found them to be organized in version 2.15 of
  90.   ANW (this is not documented in any official Novell documentation we
  91.   know of). We documented the format of NET$PRN.DAT in a separate
  92.   file (see NETPRN.ZIP in LIB 12).
  93.  
  94. - Default queue name is Q_TEXT. This is the PS-PRINT suggested queue name.
  95.   This can be changed in the source or patched in the .EXE to some
  96.   regular Novell queue name.
  97.   The queue name field in the .EXE is 47 bytes long, so the queue name
  98.   may be patch extended, as long as it's ended by a binary zero.
  99.  
  100. - Default file extension is .LST. This can be changed in either source
  101.   or .EXE.
  102.  
  103. - The "job description" field in the banner is filled with the size and
  104.   date/time stamp from the original file. We found that a good use for
  105.   this usually unused field.
  106.  
  107. - IPRINT displays the number of K's it has transfered so far to the queue.
  108.   If IPRINT output needs to be redirected, this can be disabled by using
  109.   the /S (Silent) option.
  110.  
  111.  
  112. IPRINT returns various error levels (1-16) for serious error conditions. The
  113. error levels meaning are documented in the source. Okay, documentation
  114. is in French (yes, there's life on the other side of the pond!), but the
  115. mnemonic names used for the constants are kinda English. Look ahead of the
  116. main function. If you need help, Eplex me, I do speak French. Fluently...
  117.  
  118.  
  119. Philippe Auphelle [74000,3663]
  120.  
  121.  
  122.  
  123.  
  124.  
  125. Some tech matters about IPRINT:
  126. ================================
  127.  
  128.  
  129. IPRINT uses an undocumented DOS function to normalize file path. The
  130. function works from DOS 3.0 to DOS 4.01, as far as we know. Its definition is
  131. isolated in a small separate .C module, in case one wants to change it to
  132. some plain vanilla documented algorithm, but be warned that it ain't so
  133. easy: The function does a helluva work from any partial path, including
  134. finding the server name and presenting the normalized pathname (MSNET way)
  135. as //SERVER/full path..., including when the requested file does not exist
  136. (but as long as the partial drive/path spec given exists and is syntaxically
  137. valid).
  138.  
  139. The default Q name we use is Q_TEXT. Can be patched to anything else right
  140. into the .EXE file, we oversized the name string field just for that
  141. purpose (you're allow 47 characters plus ending binary zero).
  142.  
  143. IPRINT attempts FileServerFileCopy to the Qfile. If this fails, brute force
  144. iterative copy is done. Brute force iterative copy can be forced from
  145. command line (/NC).
  146. The way we check for possible FileServerFileCopy is rather rough: We attempt
  147. it, and if it fails, we go to brute force. "Fails" is tricky to determine,
  148. since if local server copy it's not possible, Netware still returns a 0
  149. retcode (smells bug rather than feature). Try doing a FileServerFileCopy on
  150. a file off a local drive to the Qfile (or any other server file, I guess):
  151. You get a 0 retcode and a phony (kinda random) "length copied" in CX,DX. So
  152. Netware tells you the copy went okay although it couldn't do anything.
  153. I reported this to Novell, and I've been told that it will be taken care of
  154. in a future release.
  155.  
  156. We minimize the problem by only attempting FileServerFileCopy if the source
  157. file is on a network drive. This is by looking at the normalized form of the
  158. source file path.
  159. Even though, we still could have the two files on two distinct servers, and
  160. we don't know how Netware would behave then (would it still ignore the
  161. error?).
  162. The way we try to reduce the probability of the problem being unnoticed is
  163. by checking the returned "copied" length against the source file length. If
  164. by bad luck, one would IPRINT a file and the returned CX:DX would by
  165. coincidence be the exact length of the original file, IPRINT would not
  166. detect it and merrily go its way (well, not worse than a lost hardcopy
  167. listing, anyway! Will be blamed on the printer process <grin>!
  168. If this would ever happen, one could use the /NC option to get a brute force
  169. copy. I didn't spend time to find out if there was a clean, documented way
  170. to get the name of the server a file is on from its handle. Alternatively,
  171. finding the name of the server my queue is on would be okay. I could then
  172. match the server name against that of the server returned ahead of the file
  173. path by the Normalize Path DOS function.
  174.  
  175. The options that NPRINT has and IPRINT hasn't are in no way hard to implement,
  176. we just didn't do it because we didn't have an immediate need for it. Feel
  177. free to throw in the missing pieces (such as print flags setting, delete
  178. print file option, etc...). But if you do so, please post the modified code
  179. as well as its source.
  180.  
  181. If you discover problems with this program, you may report them to
  182. me: Philippe Auphelle, [74000,3663]. 
  183. I usually connect daily, but just in case I don't for a while, use
  184. Eplex. We'll do our best to improve the situation.
  185.  
  186.